A dynamic run-time environment is responsible for managing memory for objects that are created and destroyed during the execution of a program. An object is an entity that encapsulates data and, in some languages, operations associated with the object. Since the encapsulated data is stored in memory, objects are associated with particular regions of memory that are allocated and deallocated by the dynamic run-time environment.
One popular dynamic run-time environment is a JAVA™ virtual machine, which supports a platform-independent, object-oriented language developed by Sun Microsystems. In JAVA™, the attributes and methods for a class of objects are typically defined in a source file, which is compiled into an architecture-neutral object file containing bytecodes that are interpreted in the virtual machine at the target platform. It is common for objects to reference other objects.
Many object-oriented languages, including JAVA™ and C++, support the notion of a class variable, which is allocated once per class, not once per object that is an instance of a class. Class variables are often called “static” because they declared using the “static” keyword in JAVA™ and C++. Typically, the run-time environment allocates memory for class variables the first time the class is encountered or loaded. All objects belonging to the class share the same copy of the class variables, and the class variables can be access through an object belonging to the class or the class itself.
Lately, there has been much interest in using JAVA™ in a multi-user environment that allows multiple users to connect in separate, concurrent sessions to a server system, such as a relational database system. When designing a run-time environment for such a multi-user environment, scalability in terms of the number of simultaneous users who can establish separate sessions is very important.
A significant constraint for user scalability is the size of the memory “footprint” that each session consumes. For example, a server system may have 100 Mb of memory for supporting all the user sessions. If the session memory footprint is 1 Mb, then only 100 user sessions can be supported at one time. Therefore, it is desirable to reduce the session memory footprint to improve scalability. One approach for reducing the session memory footprint in a run-time environment is to allocate a single copy of objects, code, and constant data in a globally shared read-only memory rather than in a session memory that is devoted to a single session. In the example, if 500 Kb of the 1 Mb session memory footprint can be shared between the different sessions, then 500 Kb of the total 100 Mb can be reserved as a global shared read-only memory, and the remaining the 99.5 Mb would available for the individual session memories. Since the session memory requirements has dropped to 500 Kb, a total of 199 user sessions can now be supported. Consequently, session memory reduction by using globally shared read-only memory is a promising approach for improving scalability of the multi-user run-time environment.
Static class variables, however, are generally not shared between different sessions because each user may store individualized values in the static class variable that differs from that of other users. Accordingly, static class variables are not stored in a globally shared read-only memory, and there is therefore a need for managing static class variables as efficiently as possible.